500 MB Nyheder Direkte fra Internet 2/500 MB nyheder direkte fra internet CD 2.iso/start/data/text/tc15-234.txt

Text File | 1995-05-12 | 22KB | 546 lines

From [e-mail]  Tue May  9 23:19:35 1995
by
1995
23:19:35 -0400
telecomlist-outbound; Tue, 9 May 1995 20:42:00 -0500
1995
20:41:57 -0500
To: [e-mail]


TELECOM Digest     Tue, 9 May 95 20:42:00 CDT    Volume 15 : Issue 234

Inside This Issue:                          Editor: Patrick A. Townson

    Request U.S. Carrier or Integrator Response re - VTC (Brian
Caldwell)
    Re: Mexico Billing Method: Digit Analysis or Meter Pulse? (Richard
Cox)
    Re: Mexico Billing Method: Digit Analysis or Meter Pulse? (John
Brissenden)
    Re: Can Someone Explain DID in English? (Eric A. Carr)
    Caller ID Nationally and FCC Order (Matt Simpson)
    Re: Outgoing Only Phone Line Without Phone Number (Mark Cuccia)
    Re: What's R2 Signalling on Switch? (Glenn Shirley)
    Re: What's R2 Signalling on Switch? (Wally Ritchie)
    Re: Voice/Data Multiplexer For 64kb Leased Line? (Wally Ritchie)
    Re: International Telephone Number Length - Maximum Allowed (T.
Jarnbjo)
    Re: The AT&T "Minimum Usage Charge" Rumor (Bob Schwartz)
    Re: AT&T $5 Minimum Monthly Charge ([e-mail])

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and America
On Line. It is also gatewayed to Usenet where it appears as the
moderated
newsgroup 'comp.dcom.telecom'.

Subscriptions are available to qualified organizations and individual
readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: [phone]
                        Fax: [phone]
  ** Article submission address only: [e-mail] **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

************************************************************************
*
*   TELECOM Digest is partially funded by a grant from the
*
* International Telecommunication Union (ITU) in Geneva, Switzerland
*
* under the aegis of its Telecom Information Exchange Services (TIES)
*
* project.  Views expressed herein should not be construed as represent-
*
* ing views of the ITU.
*
************************************************************************
*

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your help
is important and appreciated. A suggested donation of twenty dollars per
year per reader is considered appropriate. See our address above.

All opinions expressed herein are deemed to be those of the author. Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------



Our architectural and engineering firm, headquartered in the UK,
requests
information about your U.S. corporation's capabilities regards providing
the following under a sole source contact:

U.S. video teleconferencing sites for our client, a European scientific
corporation opening offices this fall and winter in NY, Washington DC,
Baltimore, Norfolk, Atlanta, and 4 other eastern US locations.

Primary VTC traffic to be between US sites @ 384/512 Kbps video + audio
and up to 384 simultaneous data/file transfer for numerous multiplexed
medical/scientific applications during video conferences.

Nearly all calls to be point to point, but your firm would
need to provide MCU on selection. Some traffic overseas to Belgium,
France, UK, Sweden, and Italy.

Carrier or systems Integrator would need to have consulting
capabilities, or to be able to propose voice/data traffic solutions
for intra US and to European sites.

Your company would additionally need have creative design/build, or
consultative, capabilities for advanced video conferencing facilities,
which will also be used for group scientific/medical multimedia
presention.

In your response, please include senior-level marketing contact and
systems integration contacts, as well as information about your
company's size, VTC, network, and technical support capabilities, and
experience in these fields.

Kindly send this information to this Email address, or and/or by
attached electronic file transfer ("zipped" or "stuffed" compressed
files only).

If you have an electronic presentation about your firm, and/or CAD
illustrations of recent work, that will be considered by the client to
be
_extremely_ responsive.

We prefer AOL electronic file transfer attachments.

We request these to be:

Text:           PC or MacIntosh - Microsoft or Claris Works,
Graphics:    PC or MacIntosh  - Microsoft PowerPoint
CAD:           MiniCad or AutoCad in DXF format (only - not DGS).
(Again any file transfers must be "zipped" or "stuffed".)

On submission of your company's profile, statement of capabilities,
and POC's, our offices will respond immediately to any technical,
network or other inquiries.


Many thanks,

Brian Caldwell      Leeds, Caldwell, and Dickson, Ltd.

------------------------------



Jan Hinnerk Haul <[e-mail]> wrote:

> Most countries (errr... PTTs / carriers) give call supervision data
> to the PBX in some form or the other.

Up to now the UK has not done this reliably -- i.e. if you are
fortunate you may get it but you can't complain if you don't.  As a
result most people tend to work on the assumption that they don't have
it.

> Typical methods are high-frequency pulses on top of the voice signal

Hey!  That's not call supervision, that's charging information, and
that *is* available in the UK, for a quarterly fee per (analog) line.

> The drawback of number analysis is, of course, that no call
supervision
> is possible, letting users being "billed" with uncompleted calls

In the raw state, yes: but British Telecom (BT)is now proposing to
abandon the meter pulses because it will very soon be abandoning
meters (and their unit periods) and going to full per-second charging
for all dialled calls.  When it does, digit analysis will be the only
option for PBXs but to avoid the problems of false/phantom call
supervision, BT have undertaken to send supervision data to the PBX in
the form of a polarity reversal.

The changes are expected around August this year.


Richard D G Cox

Mandarin Technology, PO Box 111, Penarth, South Glamorgan CF64 3YG
Voice: 0973 311111;    Fax: [phone];    VoiceMail: 0941 151515
e-mail address: [e-mail]; PGP2.6 public key on request

------------------------------



After being asked to elaborate more on this question, here's a bit more
...

In many other countries, the telco supplies the actual cost of a call
in the form of a metered pulse count.  The derivation is that a low
frequency pulse is transmitted along the route and detected by PBXs.
Far away places send more pulses per minute than closer places.
Anyway, the important thing here is that the SMDR output on a PBX
contains a pulse field.  For billing, a site can simply multiply the
pulses times a costperpulse for an accurate cost.  With digit
analysis, one has to find the distance of the call and multiply it by
some band cost. (Yuch).  Obviously, for call billing, it's much easier
to use metered pulses, as many other countries do.


John

------------------------------



In article <[e-mail]>, marshall leathers
<leathers@bnr.
ca> wrote:

> DID or Direct Inward Dialing:

<snip>

This might help clarify.

DID is a way of automatically routing a call to a stationserved by a
PBX that originates from the local PSTN, doing so without user
intervention; i.e. an attendant.  The originating party simply dials
the directory number of the called station and the call is routed
accordingly through the PSTN to the local CO, to the PBX, then to the
called station served by the PBX.  The PBX establishes the final
connection.

With a DID trunk, the local CO assigns blocks of numbers to that trunk
(or group if there is more than one trunk assigned to the PBX), such
as NXX-1000 through NXX-1099 for example.  The local CO "knows" that
any numbers within this range are to be routed to the PBX via the DID
trunk, using DTMF or pulse dialing, serving the PBX.  The PBX, in
turn, "knows" which station set it serves that each string of digits
represents.  The CO doesn't necessarily send the entire digit string;
in the block of numbers used in the example, 100 total individual
numbers are represented.  Only the last two numbers (00 through 99) are
required to convey the called station set's address, so in this case
the CO may only send the last two digits.  It could send more, but for
this example it only needs to send two.

The PBX provides talk battery to the DID wire pair originating from
the local CO, which senses this to keep the trunks "turned up" or in
service.  If a call to a number assigned to the DID trunk comes to the
CO serving the PBX, the CO seizes the trunk by placing a short across
the wire pair.  The PBX senses the flow of current and places digit
collection equipment across the line. Once the PBX determines it's
ready to receive digits, it performs a predetermined handshake;
"wink", "delay", or "immediate", wink being the most common.  After
detecting the handshake, the CO passes the dialed digits via DTMF or
pulse dial to the PBX, which translates the digits to a station
address and routes the call to that station.

The PBX generates call progression tones and also conveys answer
supervision to the network.  If the called station goes off hook, the
PBX again reverses loop polarity but for the duration of the call
which signals the CO the called station answered.  When the called
station goes on hook (the PBX side), the PBX returns the line to
normal polarity to signal the CO that the call is over.  If the
calling party goes on hook (the CO side) , the serving CO opens the
loop, stopping loop current, to tell the PBX the call is to be ended.

A good source of further technical reading on this and other PBX
related issues can be found in the EIA/TIA RS-464 publication.


Eric Carr    [e-mail]

------------------------------



I assume that all the stuff the FCC is doing applies only to
interstate calls. Does anyone know if the LECs will ever be required
to transmit caller-id on intra-state, intra-LATA calls? Is this
something the PSC in each state needs to address? For example, I
live in Paris, KY and get my phone service (including caller-id) from
South Central Bell. Many of my calls come from Lexington, KY, about 20
miles away. Same LATA, but served by GTE. I don't get caller-id on any
of those calls. I know my local switch is capable of picking up
caller-id from long-distance calls, because I occasionally get it on
other calls. So I assume the reason I don't get it on calls from
Lexington is that GTE doesn't send it. GTE does provide caller-id to
Lexington customers, so I know they're at least capable of delivering
it locally. And Lexington has lots of different exchanges and several
COs, so I assume GTE is capable of transmitting the id between their
own switches. So why don't they send it to South Central Bell? Is
there some technical reason? Or are they just being stubborn? And is
there any chance that they'll stop being stubborn?


Matt Simpson --  Lead Systems Programmer - MVS
University Of Kentucky, Lexington, KY
[e-mail]     http://rivendell.cc.uky.edu

------------------------------



In John D. Galt's recent post, he states that 01 uses for a 'non-dial'
number would be confused with International Dialing sequences.

There are various semi-interrelated numbering schemes used by telco:

     1. Dialable numbers by operators & customers (including certain
codes,
011+ International Access)

     2. Dial-ACCESS codes for CUSTOMER use (1+, 0+, and for
opr.asstd.intl.
01+; ALSO 10XXX/101XXXX+)

     3. Operator/Network SYSTEM codes of the form 1XX and 0XX -- these
are
NOT used by the general customer -- they are used by the operators and
Test personnel, etc. Operators do NOT use a 1+ when dialing out for a
customer, ergo 1XX used by an operator would not conflict. These are
used for special routing, network control, opr.to opr.connections,
etc.

     4. Internal BILLING codes for identification of a party for BILLING
purposes - used for manual Ring Down points, and used for OutWATS-"only"
lines - these have been of the form 88X, and 0XX/1XX.  Sometimes they
are of
the form of a LETTER followed by 2 digits for Private Leased Circuits -
These are more or less an ACCOUNT number - They are NOT dialed by the
customer and not even the OPERATOR - the Opr.will key the 7 or 10 digit
string into the BILLING database for automated billing - YEARS ago, the
opr.would write up a toll-ticket which would be processed manually to
prepare the billed party's monthly bill. Sometimes these codes have been
known as 'Mark-Sense Codes' since the Operator would 'Mark' (write) a
'Sense' (digit/symbol) on the old fashioned manually written toll-
tickets.

     5. Also related to point 4, 'Non-Subscriber' Calling Cards -
These are 14 digit calling card numbers which are assigned to special
billing card accounts; includes AT&T's non-line-number based card
numbers but billed to a home/residence regular telephone number bill
(I am NOT really referring to MAX 13 digit AT&T cards where you pick
the card number).  When placing a call, the Operator will key the
number into the billing/validation database, first to verify/validate
the number, and if ok it is recorded into billing equipment and the
call goes thru.  Customers can ALSO key this type of number AFTER
reaching a TOPS/TSPS/OSPS system when using their card on an automated
basis.  NOTE: you as the customer are NOT keying your card number as a
call destination but rather as a billing number and you are entering
it into the operator's validation database, not the routing/switching
network for the call.  These numbering sequences also inter-relate
with 'RAO' codes (Revenue Accounting Office) used for billing message
relaying among the carriers.

Bellcore's TRA, North American Numbering, and RAO/CIID divisions are
responsible for managing the numbering issues amongst the various
carriers in North America, along with regulatory agencies, the local
telcos themselves, and various Industry Forums. They inherited this
role from AT&T Long Lines beginning in 1984.

Numbering/Dialing issues are NOT always that easy and simple. You have
to know WHERE, HOW, WHY, WHICH particular numbering sequence is used
and the network or database, etc. is applied.

Oh BTW, Bellcore has plans to unload their North American Numbering
Plan Administration (but probably NOT TRA)- This began after the FCC
started a Notice of Inquiry back in '92 - NOTHING has yet been finalized
on this matter.


MARK

------------------------------



[e-mail] (Yee-Lee Shyong) writes:

> Originally, I only heard about TR-008 or TR-303 for signaling
> specification between Digital Loop Carrier(DLC) and Local Digital
> Switch (LDS). But somebody tols me that R2 signaling is also popular
on
> LDS. Can someone out there tell me what it is? Where I can find this
> document describibg R2? Who published that material?

Its one of the CCITT Blue Book Recommendations (I think). Its based
around multi-frequency signalling with each end sending its signal
until the other end replies by sending an acknowledge/send next
signal, also in the form of multi-frequency.

Most countries make changes to the spec. (which the spec. actually
allows for by having user defined signals).  I just had to spend 5
weeks in China installing a cellular system with the Chinese
equivalent of R2 (Chinese MFC) for connections to the local exchanges.


╖_


If you don't get any replies with the exact volume and fascicle for
this spec. mail me ([e-mail]) and I'll forward
the information to you when I'm at work on Monday.


Glenn

------------------------------



In <[e-mail]>, [e-mail]
(Yee-Lee Shyong) writes:

> Originally, I only heard about TR-008 or TR-303 for signaling
> specification between Digital Loop Carrier(DLC) and Local Digital
> Switch (LDS). But somebody tols me that R2 signaling is also popular
on
> LDS. Can someone out there tell me what it is? Where I can find this
> document describibg R2? Who published that material?

R2 is defined in the ITU-T Q Series documents which you can get from
the ITU gopher at info.itu.ch

R2 is a compelled form of signalling used primarily on International
Gateway connections. Never heard of it being used in the US at other
than International Gateways.


Hope this helps.

Wally Ritchie      Ft. Lauderdale, Florida

------------------------------



In <[e-mail]>, [e-mail] (Magnus
Harlander) writes:

> We are looking for a data/voice multiplexer for a leased 64kb
> digital line. We want to use some portion of the bandwidth for phone
> calls to and from a PBX extension and the rest for IP traffic. The
> leased line speaks the G.703 protocol (there would be an alternative
> using I.430). Any information about implementations, producers and
> distributors is appreciated.


Newbridge Networks (3606) (Canada)
Republic Telecom (Now Netrix) (RLX400) (US)
Micom (Marathon Series) (US)
Case (UK)

If you have trouble finding phone number e-mail me and I'll dig them
out.


Wally Ritchie      Ft. Lauderdale, Florida

------------------------------



[e-mail] wrote:

> One limitation that was discussed here in July '93 is that -- from the
> US at least -- an international call may not have more than 12 digits,
> e.g. dialing the following number in Germany:
>      011 +49 6131 XXX 4555
> results after some time in a short beep and then a busy signal.
> On the other hand:
>      011 +49 6131 XXX 450
> works just fine.

[snip]

> direct dial from a local exchange in the United States!!  (As I was
> told there are 13-digit numbers currently in Germany, Austria, and the
> Chech Republic.)

Actually phone-numbers assigned by German Telekom does not exceed 12
digits (country-code + area-code + local number). The number you
mention (0 61 31) X XX 45-55 is a local line within the PBX on number
(0 61 31) XX X45. Normally PBX-lines are denotated as (0 areacode)
XXXX-YYYY where XXXX is the phonennumber and YYYY the local number.
The manual switchboard is (always) then available at XXXX-0 which
means that all German phone-number are dialable from US :)


Tor-Einar Jarnbjo, [e-mail]

------------------------------



In article <[e-mail]>, [e-mail]
wrote:

> I essentially never make LD calls and would be happy to have no LD
> provider at all.

> [TELECOM Digest Editor's Note:  ... even if telco defaults your line
to
> 'none', you will still have to pay the network access charge each
month
> since you can access carriers you choose via 10xxx.  PAT]

One other issue that is often missed on the topic: You still have to
pay the network access charge for the ability to RECEIVE long distance
calls.


BOB

------------------------------



Pat said:

> [TELECOM Digest Editor's Note: Each of the carriers leases a large
amount
> of the resources and facilities of the other carriers. MCI purchases a
few
> million dollars worth of leased circuits from AT&T monthly. If there
is
> any single customer (a large corporation, I assume) doing more
business
> with AT&T monthly, I would like to know who they are. Anyone who has
some
> actual dollar figures available want to comment on this?    PAT]

The BofA contract with MCI is the largest private contract the company
has landed. Many years ago (ten or more) a lot of traffic was carried
over other IECs.  Those days are long gone. AT&T doesn't switch our
traffic, we don't switch theirs. We don't lease any AT&T facilities,
but might use some short fiber routes of theirs in remote areas where
it's not cost effective to install our own.  Bottom line really is
that AT&T is not a million dollar customer of MCIs.  Now how much do we
pay the RBOCs? That's another story!! :)


Iguana

------------------------------

End of TELECOM Digest V15 #234
******************************